﻿<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><!--
 Archive processed by SingleFile 
 url: https://tools.ietf.org/html/rfc6218 
 saved date: Sat Oct 18 2014 04:06:42 GMT+0300 (Финляндия (лето)) 
--><head profile="http://dublincore.org/documents/2008/08/04/dc-html/">
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <meta name="robots" content="index,follow">
    <meta name="creator" content="rfcmarkup version 1.108">
    <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
<meta name="DC.Identifier" content="urn:ietf:rfc:6218">
<meta name="DC.Description.Abstract" content="This document defines a set of vendor-specific RADIUS Attributes\ndesigned to allow both the secure transmission of cryptographic keying\nmaterial and strong authentication of any RADIUS message. These\nattributes have been allocated from the Cisco vendor-specific space\nand have been implemented by multiple vendors. This document is not an\nInternet Standards Track specification; it is published for\ninformational purposes.">
<meta name="DC.Creator" content="Zorn, Glen">
<meta name="DC.Creator" content="Zhang, Tiebing">
<meta name="DC.Creator" content="Walker, Jesse">
<meta name="DC.Creator" content="Salowey, Joseph">
<meta name="DC.Date.Issued" content="April, 2011">
<meta name="DC.Title" content="Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material">

    <link rel="icon" href="" type="image/png">
    <link rel="shortcut icon" href="" type="image/png">
    <title>RFC 6218 - Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material</title>
    
    
    <style type="text/css">
	body {
	    margin: 0px 8px;
            font-size: 1em;
	}
        h1, h2, h3, h4, h5, h6, .h1, .h2, .h3, .h4, .h5, .h6 {
	    font-weight: bold;
            line-height: 0pt;
            display: inline;
            white-space: pre;
            font-family: monospace;
            font-size: 1em;
	    font-weight: bold;
        }
        pre {
            font-size: 1em;
            margin-top: 0px;
            margin-bottom: 0px;
        }
	.pre {
	    white-space: pre;
	    font-family: monospace;
	}
	.header{
	    font-weight: bold;
	}
        .newpage {
            page-break-before: always;
        }
        .invisible {
            text-decoration: none;
            color: white;
        }
        a.selflink {
          color: black;
          text-decoration: none;
        }
        @media print {
            body {
                font-family: monospace;
                font-size: 10.5pt;
            }
            h1, h2, h3, h4, h5, h6 {
                font-size: 1em;
            }
        
            a:link, a:visited {
                color: inherit;
                text-decoration: none;
            }
            .noprint {
                display: none;
            }
        }
	@media screen {
	    .grey, .grey a:link, .grey a:visited {
		color: #777;
	    }
            .docinfo {
                background-color: #EEE;
            }
            .top {
                border-top: 7px solid #EEE;
            }
            .bgwhite  { background-color: white; }
            .bgred    { background-color: #F44; }
            .bggrey   { background-color: #666; }
            .bgbrown  { background-color: #840; }            
            .bgorange { background-color: #FA0; }
            .bgyellow { background-color: #EE0; }
            .bgmagenta{ background-color: #F4F; }
            .bgblue   { background-color: #66F; }
            .bgcyan   { background-color: #4DD; }
            .bggreen  { background-color: #4F4; }

            .legend   { font-size: 90%; }
            .cplate   { font-size: 70%; border: solid grey 1px; }
	}
    </style>
    <!--[if IE]>
    <style>
    body {
       font-size: 13px;
       margin: 10px 10px;
    }
    </style>
    <![endif]-->

    
</head>
<body>
   <div style="height: 13px;">
      <div onmouseover="this.style.cursor='pointer';" onclick="showElem('legend');" onmouseout="hideElem('legend')" style="height: 6px; position: absolute;" class="pre noprint docinfo bgorange" title="Click for colour legend.">                                                                        </div>
      <div id="legend" class="docinfo noprint pre legend" style="position:absolute; top: 4px; left: 4ex; visibility:hidden; background-color: white; padding: 4px 9px 5px 7px; border: solid #345 1px; " onmouseover="showElem('legend');" onmouseout="hideElem('legend');">
      </div>
   </div>
<span class="pre noprint docinfo top">[<a href="https://tools.ietf.org/html" title="Document search and retrieval page">Docs</a>] [<a href="https://tools.ietf.org/rfc/rfc6218.txt" title="Plaintext version of this document">txt</a>|<a href="https://tools.ietf.org/pdf/rfc6218" title="PDF version of this document">pdf</a>] [<a href="https://tools.ietf.org/html/draft-zorn-radius-keywrap" title="draft-zorn-radius-keywrap">draft-zorn-radius...</a>] [<a href="https://tools.ietf.org/rfcdiff?difftype=--hwdiff&amp;url2=rfc6218" title="Inline diff (wdiff)">Diff1</a>] [<a href="https://tools.ietf.org/rfcdiff?url2=rfc6218" title="Side-by-side diff">Diff2</a>]                 </span><br>
<span class="pre noprint docinfo">                                                                        </span><br>
<span class="pre noprint docinfo">                                                           INFORMATIONAL</span><br>
<span class="pre noprint docinfo">                                                                        </span><br>
<pre>Independent Submission                                           G. Zorn
Request for Comments: 6218                                   Network Zen
Category: Informational                                         T. Zhang
ISSN: 2070-1721                                     Advista Technologies
                                                               J. Walker
                                                       Intel Corporation
                                                              J. Salowey
                                                           Cisco Systems
                                                              April 2011


              <span class="h1"><h1>Cisco Vendor-Specific RADIUS Attributes for</h1></span>
                    <span class="h1"><h1>the Delivery of Keying Material</h1></span>

Abstract

   This document defines a set of vendor-specific RADIUS Attributes
   designed to allow both the secure transmission of cryptographic
   keying material and strong authentication of any RADIUS message.
   These attributes have been allocated from the Cisco vendor-specific
   space and have been implemented by multiple vendors.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This is a contribution to the RFC Series, independently of any other
   RFC stream.  The RFC Editor has chosen to publish this document at
   its discretion and makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are not a candidate for any level of Internet
   Standard; see <a href="https://tools.ietf.org/html/rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc6218">http://www.rfc-editor.org/info/rfc6218</a>.

IESG Note

   The IESG has concluded that this work is related to IETF work done in
   the RADEXT WG, but this relationship does not prevent publishing.
   The IESG recommends that the RADEXT WG proceed with the work for an
   interoperable modern key wrap solution using attributes from the
   standard space as part of its charter.






<span class="grey">Zorn, et al.                  Informational                     [Page 1]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-2" id="page-2" href="#page-2" class="invisible"> </a>
<span class="grey"><a href="https://tools.ietf.org/html/rfc6218">RFC 6218</a>           RADIUS Keying Material Transfer VSA        April 2011</span>


Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://tools.ietf.org/html/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
   <a href="#section-2">2</a>. Specification of Requirements ...................................<a href="#page-3">3</a>
   <a href="#section-3">3</a>. Attributes ......................................................<a href="#page-3">3</a>
      <a href="#section-3.1">3.1</a>. Keying-Material ............................................<a href="#page-4">4</a>
      <a href="#section-3.2">3.2</a>. MAC-Randomizer .............................................<a href="#page-9">9</a>
      <a href="#section-3.3">3.3</a>. Message-Authentication-Code ...............................<a href="#page-11">11</a>
   <a href="#section-4">4</a>. Security Considerations ........................................<a href="#page-16">16</a>
   <a href="#section-5">5</a>. Contributors ...................................................<a href="#page-16">16</a>
   <a href="#section-6">6</a>. Acknowledgements ...............................................<a href="#page-16">16</a>
   <a href="#section-7">7</a>. References .....................................................<a href="#page-16">16</a>
      <a href="#section-7.1">7.1</a>. Normative References ......................................<a href="#page-16">16</a>
      <a href="#section-7.2">7.2</a>. Informative References ....................................<a href="#page-17">17</a>

<span class="h2"><h2><a class="selflink" name="section-1" href="#section-1">1</a>.  Introduction</h2></span>

   This document defines a set of vendor-specific RADIUS Attributes,
   allocated from the Cisco vendor space, that can be used to securely
   transfer cryptographic keying material using standard techniques with
   well-understood security properties.  In addition, the Message-
   Authentication-Code Attribute may be used to provide strong
   authentication for any RADIUS message, including those used for
   accounting and dynamic authorization.

   These attributes were designed to provide stronger protection and
   more flexibility than the currently defined Vendor-Specific
   MS-MPPE-Send-Key and MS-MPPE-Recv-Key Attributes in [<a href="https://tools.ietf.org/html/rfc2548" title="&quot;Microsoft Vendor-specific RADIUS Attributes&quot;">RFC2548</a>] and the
   Message-Authenticator Attribute in [<a href="https://tools.ietf.org/html/rfc3579" title="&quot;RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)&quot;">RFC3579</a>].

   Many remote access deployments (for example, deployments utilizing
   wireless LAN technology) require the secure transmission of
   cryptographic keying material from a RADIUS [<a href="https://tools.ietf.org/html/rfc2865" title="&quot;Remote Authentication Dial In User Service (RADIUS)&quot;">RFC2865</a>] server to a
   network access point.  This material is usually produced as a
   by-product of an Extensible Authentication Protocol (EAP) [<a href="https://tools.ietf.org/html/rfc3748" title="&quot;Extensible Authentication Protocol (EAP)&quot;">RFC3748</a>]
   authentication and returned in the Access-Accept message following a



<span class="grey">Zorn, et al.                  Informational                     [Page 2]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-3" id="page-3" href="#page-3" class="invisible"> </a>
<span class="grey"><a href="https://tools.ietf.org/html/rfc6218">RFC 6218</a>           RADIUS Keying Material Transfer VSA        April 2011</span>


   successful authentication process.  The keying material is of a form
   that may be used in virtually any cryptographic algorithm after
   appropriate processing.  These attributes may also be used in other
   cases where an Authentication, Authorization, and Accounting (AAA)
   server needs to deliver keying material to a network access point.

   Discussion of this document may be directed to the authors.

<span class="h2"><h2><a class="selflink" name="section-2" href="#section-2">2</a>.  Specification of Requirements</h2></span>

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [<a href="https://tools.ietf.org/html/rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

<span class="h2"><h2><a class="selflink" name="section-3" href="#section-3">3</a>.  Attributes</h2></span>

   The following subsections describe sub-attributes that are
   transmitted in RADIUS Attributes of type Vendor-Specific [<a href="https://tools.ietf.org/html/rfc2865" title="&quot;Remote Authentication Dial In User Service (RADIUS)&quot;">RFC2865</a>].
   The Vendor ID field of the Vendor-Specific Attribute(s) MUST be set
   to decimal 9 (Cisco).  The general format of the attributes is:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type (26)   |    Length   |         Vendor ID
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Vendor ID (cont'd)           |   Sub-type (1)|   Sub-length  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Value...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      26 for Vendor-Specific

   Length

      Length of entire attribute including type and length fields

   Vendor ID

      4 octets encoding the Cisco Vendor ID of 9

   Sub-type

      Attribute sub-type of 1





<span class="grey">Zorn, et al.                  Informational                     [Page 3]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-4" id="page-4" href="#page-4" class="invisible"> </a>
<span class="grey"><a href="https://tools.ietf.org/html/rfc6218">RFC 6218</a>           RADIUS Keying Material Transfer VSA        April 2011</span>


   Sub-length

      Length of the sub-attribute including the sub-type and sub-length
      fields

   Value

      Value of the sub-attribute

   This specification concerns the following sub-attributes:

   o  Keying-Material

   o  MAC-Randomizer

   o  Message-Authentication-Code

<span class="h3"><h3><a class="selflink" name="section-3.1" href="#section-3.1">3.1</a>.  Keying-Material</h3></span>

   Description

      This Attribute MAY be used to transfer cryptographic keying
      material from a RADIUS server to a client.

      It MAY be sent in request messages (e.g., Access-Request, etc.),
      as well; if the Keying-Material (KM) Attribute is present in a
      request, it SHOULD be taken as a hint by the server that the
      client prefers this method of key delivery over others.  The
      server is not obligated to honor the hint, however.  When the
      Keying-Material Attribute is included in a request message, the KM
      ID, key-encrypting-key (KEK) ID, Lifetime, Initialization Vector
      (IV), and Key Material Data fields MAY be omitted.

      In environments where the Keying-Material Attribute is known to be
      supported or in cases where the client wants to avoid roll-back
      attacks, the client MAY be configured to require the use of the
      Keying-Material Attribute.  If the client requires the use of the
      Keying-Material Attribute for keying material delivery and it is
      not present in the Access-Accept or Access-Challenge message, the
      client MAY ignore the message in question and end the user
      session.










<span class="grey">Zorn, et al.                  Informational                     [Page 4]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-5" id="page-5" href="#page-5" class="invisible"> </a>
<span class="grey"><a href="https://tools.ietf.org/html/rfc6218">RFC 6218</a>           RADIUS Keying Material Transfer VSA        April 2011</span>


      Any packet that contains a Keying-Material Attribute MUST also
      include the Message-Authentication-Code Attribute.

      Any packet that contains an instance of the Keying-Material
      Attribute MUST NOT contain an instance of any other attribute
      (e.g., MS-CHAP-MPPE-Keys [<a href="https://tools.ietf.org/html/rfc2548" title="&quot;Microsoft Vendor-specific RADIUS Attributes&quot;">RFC2548</a>], Tunnel-Password [<a href="https://tools.ietf.org/html/rfc2868" title="&quot;RADIUS Attributes for Tunnel Protocol Support&quot;">RFC2868</a>],
      etc.) encapsulating identical keying material.

      The Keying-Material Attribute MUST NOT be used to transfer long-
      lived keys (i.e., passwords) between RADIUS servers and clients.

      A summary of the Keying-Material Attribute format is shown below.
      The fields are transmitted from left to right.






































<span class="grey">Zorn, et al.                  Informational                     [Page 5]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-6" id="page-6" href="#page-6" class="invisible"> </a>
<span class="grey"><a href="https://tools.ietf.org/html/rfc6218">RFC 6218</a>           RADIUS Keying Material Transfer VSA        April 2011</span>


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type (26)   |    Length   |   Vendor ID
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Vendor ID (cont'd)           |   Sub-type (1)|    Sub-length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     String ID  ("radius:app-key=")
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              String ID (cont'd)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              String ID (cont'd)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              String ID (cont'd)     |    Enc Type   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             App ID                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             KEK ID
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                KEK ID (cont'd)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                KEK ID (cont'd)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                KEK ID (cont'd)                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             KM ID
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                KM ID (cont'd)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                KM ID (cont'd)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                KM ID (cont'd)                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Lifetime                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               IV
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                  IV (cont'd)                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Keying Material Data
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+










<span class="grey">Zorn, et al.                  Informational                     [Page 6]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-7" id="page-7" href="#page-7" class="invisible"> </a>
<span class="grey"><a href="https://tools.ietf.org/html/rfc6218">RFC 6218</a>           RADIUS Keying Material Transfer VSA        April 2011</span>


   Type

      26 for Vendor-Specific

   Length

      Length of entire attribute including type and length fields

   Vendor ID

      4 octets encoding the Cisco Vendor ID of 9

   Sub-type

      Attribute sub-type of 1

   Sub-length

      Length of the sub-attribute including the sub-type and sub-length
      fields

   String-ID

      The ASCII characters "radius:app-key=" without quotes or null
      termination

   Enc Type

      The Enc Type field indicates the method used to encrypt the
      contents of the Data field.  This document defines only one value
      (decimal) for this field:

         0 AES Key Wrap with 128-bit KEK [<a href="https://tools.ietf.org/html/rfc3394" title="&quot;Advanced Encryption Standard (AES) Key Wrap Algorithm&quot;">RFC3394</a>]

      Implementations MUST support Enc Type 0 (AES Key Wrap with 128-bit
      KEK).

      Implementation Note

         A shared secret is used as the key-encrypting-key (KEK) for the
         AES key wrap algorithm.  Implementations SHOULD provide a means
         to provision a key (cryptographically separate from the normal
         RADIUS shared secret) to be used exclusively as a KEK.








<span class="grey">Zorn, et al.                  Informational                     [Page 7]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-8" id="page-8" href="#page-8" class="invisible"> </a>
<span class="grey"><a href="https://tools.ietf.org/html/rfc6218">RFC 6218</a>           RADIUS Keying Material Transfer VSA        April 2011</span>


   App ID

      The App ID field is 4 octets in length and identifies the type of
      application for which the key material is to be used.  This allows
      for multiple keys for different purposes to be present in the same
      message.  This document defines two values for the App ID:

         0 Reserved

         1 EAP MSK

   KEK ID

      The KEK ID field is 16 octets in length.  The combination of the
      KEK ID and the client and server IP addresses together uniquely
      identify a key shared between the RADIUS client and server.  As a
      result, the KEK ID need not be globally unique.  The KEK ID MUST
      refer to an encryption key of a type and length appropriate for
      use with the algorithm specified by the Enc Type field (see
      above).  This key is used to protect the contents of the Data
      field (below).  The KEK ID is a constant that is configured
      through an out-of-band mechanism.  The same value is configured on
      both the RADIUS client and server.  If no KEK ID is configured,
      then the field is set to 0.  If only a single KEK is configured
      for use between a given RADIUS client and server, then 0 can be
      used as the default value.

   KM ID

      The KM ID field is 16 octets in length and contains an identifier
      for the contents of the Data field.  The KM ID MAY be used by
      communicating parties to identify the material being transmitted.
      The combination of App ID and KM ID MUST uniquely identify the
      keying material between the parties utilizing it.  The KM ID is
      assumed to be known to the parties that derived the keying
      material.  If the KM ID is not used, it is set to 0.  The KM ID
      for the EAP Master Session Key (MSK) application is set to 0.
      Another application that uses the KM ID field can be defined in
      the future.

   Lifetime

      The Lifetime field is an integer [<a href="https://tools.ietf.org/html/rfc2865" title="&quot;Remote Authentication Dial In User Service (RADIUS)&quot;">RFC2865</a>] representing the period
      of time (in seconds) for which the keying material is valid.

      Note: Applications using this value SHOULD consider the beginning
      of the lifetime to be the point in time when the keying material
      is first used.



<span class="grey">Zorn, et al.                  Informational                     [Page 8]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-9" id="page-9" href="#page-9" class="invisible"> </a>
<span class="grey"><a href="https://tools.ietf.org/html/rfc6218">RFC 6218</a>           RADIUS Keying Material Transfer VSA        April 2011</span>


   IV

      The length of the IV field depends upon the value of the Enc Type
      field, but is fixed for any given value thereof.  When the value
      of the Enc Type field is 0 (decimal), the IV field MUST be 8
      octets in length (as illustrated above), and the value of the IV
      field MUST be as specified in [<a href="https://tools.ietf.org/html/rfc3394" title="&quot;Advanced Encryption Standard (AES) Key Wrap Algorithm&quot;">RFC3394</a>].  If the IV for Enc Type 0
      does not match [<a href="https://tools.ietf.org/html/rfc3394" title="&quot;Advanced Encryption Standard (AES) Key Wrap Algorithm&quot;">RFC3394</a>], then the receiver MUST NOT use the key
      material from this attribute.

   Keying Material Data

      The Keying Material Data field is of variable length and contains
      the actual encrypted keying material.

<span class="h3"><h3><a class="selflink" name="section-3.2" href="#section-3.2">3.2</a>.  MAC-Randomizer</h3></span>

   Description

      The MAC-Randomizer Attribute MUST be present in any message that
      includes an instance of the Message-Authentication-Code Attribute.
      The Random field MUST contain a 32-octet random number that SHOULD
      satisfy the requirements of [<a href="https://tools.ietf.org/html/rfc4086" title="&quot;Randomness Requirements for Security&quot;">RFC4086</a>].

      Implementation Note

         The Random field MUST be filled in before the Message
         Authentication Code (MAC) is computed.  The MAC-Randomizer
         Attribute SHOULD be placed at the beginning of the RADIUS
         message if possible.

      A summary of the MAC-Randomizer Attribute format is shown below.
      The fields are transmitted from left to right.


















<span class="grey">Zorn, et al.                  Informational                     [Page 9]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-10" id="page-10" href="#page-10" class="invisible"> </a>
<span class="grey"><a href="https://tools.ietf.org/html/rfc6218">RFC 6218</a>           RADIUS Keying Material Transfer VSA        April 2011</span>


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type (26)   |    Length   |   Vendor ID
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Vendor ID (cont'd)           |   Sub-type (1)|    Sub-length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     String ID  ("radius:random-nonce=")
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              String ID (cont'd)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              String ID (cont'd)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              String ID (cont'd)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              String ID (cont'd)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Random...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         26 for Vendor-Specific

      Length

         Length of entire attribute including type and length fields

      Vendor ID

         4 octets encoding the Cisco Vendor ID of 9

      Sub-type

         Attribute sub-type of 1

      Sub-length

         Length of the sub-attribute including the sub-type and
         sub-length fields

      String-ID

         The ASCII characters "radius:random-nonce=" without quotes or
         null termination






<span class="grey">Zorn, et al.                  Informational                    [Page 10]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-11" id="page-11" href="#page-11" class="invisible"> </a>
<span class="grey"><a href="https://tools.ietf.org/html/rfc6218">RFC 6218</a>           RADIUS Keying Material Transfer VSA        April 2011</span>


      Random

         This field MUST contain a 32 octet random number that SHOULD
         satisfy the requirements of [<a href="https://tools.ietf.org/html/rfc4086" title="&quot;Randomness Requirements for Security&quot;">RFC4086</a>].

<span class="h3"><h3><a class="selflink" name="section-3.3" href="#section-3.3">3.3</a>.  Message-Authentication-Code</h3></span>

   Description

      This Attribute MAY be used to "sign" messages to prevent spoofing.
      If it is present in a request, the receiver should take this as a
      hint that the sender prefers the use of this Attribute for message
      authentication; the receiver is not obligated to do so, however.

      The Message-Authentication-Code Attribute MUST be included in any
      message that contains a Keying-Material Attribute.

      If both the Message-Authentication-Code and Message-Authenticator
      Attributes are to be included in a message (e.g., for backward
      compatibility in a network containing both old and new clients),
      the value of the Message-Authentication-Code Attribute MUST be
      computed first.

      If any message is received containing an instance of the Message-
      Authentication-Code Attribute, the receiver MUST calculate the
      correct value of the Message-Authentication-Code and silently
      discard the packet if the computed value does not match the value
      received.

      If a received message contains an instance of the MAC-Randomizer
      Attribute (<a href="#section-3.2">Section 3.2</a>), the received MAC-Randomizer Attribute
      SHOULD be included in the computation of the Message-
      Authentication-Code Attribute sent in the response, as described
      below.

      A summary of the Message-Authentication-Code Attribute format is
      shown below.  The fields are transmitted from left to right.














<span class="grey">Zorn, et al.                  Informational                    [Page 11]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-12" id="page-12" href="#page-12" class="invisible"> </a>
<span class="grey"><a href="https://tools.ietf.org/html/rfc6218">RFC 6218</a>           RADIUS Keying Material Transfer VSA        April 2011</span>


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type (26)   |    Length   |           Vendor ID
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Vendor ID (cont'd)           |   Sub-type (1)|    Sub-length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       String ID  ("radius:message-authenticator-code=")
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              String ID (cont'd)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              String ID (cont'd)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              String ID (cont'd)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              String ID (cont'd)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              String ID (cont'd)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              String ID (cont'd)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              String ID (cont'd)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              String ID (cont'd)     |   MAC Type    |  MAC Key ID
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       MAC Key ID (cont'd)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             MAC Key ID (cont'd)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             MAC Key ID (cont'd)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             MAC Key ID (cont'd)     |    MAC
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             MAC (cont'd) ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         26 for Vendor-Specific

      Length

         Length of entire attribute including type and length fields

      Vendor ID

         4 octets encoding the Cisco Vendor ID of 9




<span class="grey">Zorn, et al.                  Informational                    [Page 12]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-13" id="page-13" href="#page-13" class="invisible"> </a>
<span class="grey"><a href="https://tools.ietf.org/html/rfc6218">RFC 6218</a>           RADIUS Keying Material Transfer VSA        April 2011</span>


      Sub-type

         Attribute sub-type of 1

      Sub-length

         Length of the sub-attribute including the sub-type and
         sub-length fields

      String-ID

         The ASCII characters "radius:message-authenticator-code="
         without quotes or null termination

      MAC Type

         The MAC Type field specifies the algorithm used to create the
         value in the MAC field.  This document defines six values for
         the MAC Type field:

            0 HMAC-SHA-1 [<a href="#ref-FIPS" title="&quot;Secure Hash Standard (SHS)&quot;">FIPS</a>] [<a href="https://tools.ietf.org/html/rfc2104" title="&quot;HMAC: Keyed- Hashing for Message Authentication&quot;">RFC2104</a>]

            1 HMAC-SHA-256 [<a href="#ref-FIPS" title="&quot;Secure Hash Standard (SHS)&quot;">FIPS</a>] [<a href="https://tools.ietf.org/html/rfc4231" title="&quot;Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512&quot;">RFC4231</a>]

            2 HMAC-SHA-512 [<a href="#ref-FIPS" title="&quot;Secure Hash Standard (SHS)&quot;">FIPS</a>] [<a href="https://tools.ietf.org/html/rfc4231" title="&quot;Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512&quot;">RFC4231</a>]

            3 CMAC-AES-128 [<a href="#ref-NIST" title="&quot;Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication&quot;">NIST</a>]

            4 CMAC-AES-192 [<a href="#ref-NIST" title="&quot;Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication&quot;">NIST</a>]

            5 CMAC-AES-256 [<a href="#ref-NIST" title="&quot;Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication&quot;">NIST</a>]

         Implementations MUST support MAC Type 0 (HMAC-SHA-1).

      MAC Key ID

         The MAC Key ID field is 16 octets in length and contains an
         identifier for the key.  The combination of the MAC Key ID and
         the client and server IP addresses together uniquely identify a
         key shared between the RADIUS client and server.  As a result,
         the MAC Key ID need not be globally unique.  The MAC Key ID
         MUST refer to a key of a type and length appropriate for use
         with the algorithm specified by the MAC Type field (see above).








<span class="grey">Zorn, et al.                  Informational                    [Page 13]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-14" id="page-14" href="#page-14" class="invisible"> </a>
<span class="grey"><a href="https://tools.ietf.org/html/rfc6218">RFC 6218</a>           RADIUS Keying Material Transfer VSA        April 2011</span>


         The MAC Key ID is a constant that is configured through an out-
         of-band mechanism.  The same value is configured on both the
         RADIUS client and server.  If no MAC Key ID is configured, then
         the field is set to 0.  If only a single MAC Key ID is
         configured for use between a given RADIUS client and server,
         then 0 can be used as the default value.

      MAC

         Both the length and value of the MAC field depend upon the
         algorithm specified by the value of the MAC Type field.  If the
         algorithm specified is HMAC-SHA-1, HMAC-SHA-256, or
         HMAC-SHA-512, the MAC field MUST be 20, 32, or 64 octets in
         length, respectively.  If the algorithm specified is
         CMAC-AES-128, CMAC-AES-192, or CMAC-AES-256, the MAC field
         SHOULD be 64 octets in length.  The derivation of the MAC field
         value for all the algorithms specified in this document is
         identical, except for the algorithm used.  There are
         differences, however, depending upon whether the MAC is being
         computed for a request message or a response.  These
         differences are detailed below, with the free variable HASH-ALG
         representing the actual algorithm used.

         Request Messages

            For requests (e.g., CoA-Request [<a href="https://tools.ietf.org/html/rfc5176" title="&quot;Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)&quot;">RFC5176</a>], Accounting-
            Request [<a href="https://tools.ietf.org/html/rfc2866" title="&quot;RADIUS Accounting&quot;">RFC2866</a>], etc.), the value of the MAC field is a
            hash of the entire packet except the Request Authenticator
            in the header of the RADIUS packet, using a shared secret as
            the key, as follows.

            MAC = MAC-ALG(Key, Type + Identifier + Length + Attributes)
               where '+' represents concatenation

            The MAC-Randomizer Attribute (<a href="#section-3.2">Section 3.2</a>) MUST be included
            in any request in which the Message-Authentication-Code
            Attribute is used.  The Random field of the MAC-Randomizer
            Attribute MUST be filled in before the value of the MAC
            field is computed.

            If the Message-Authenticator-Code Attribute is included in a
            client request, the server SHOULD ignore the contents of the
            Request Authenticator.








<span class="grey">Zorn, et al.                  Informational                    [Page 14]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-15" id="page-15" href="#page-15" class="invisible"> </a>
<span class="grey"><a href="https://tools.ietf.org/html/rfc6218">RFC 6218</a>           RADIUS Keying Material Transfer VSA        April 2011</span>


            Implementation Notes

               When the hash is calculated, both the MAC field of the
               Message-Authenticator-Code Attribute and the String field
               of the Message-Authenticator Attribute (if any) MUST be
               considered to be zero-filled.

               Implementations SHOULD provide a means to provision a key
               (cryptographically separate from the normal RADIUS shared
               secret) to be used exclusively in the generation of the
               Message-Authentication-Code.

         Response Messages

            For responses (e.g., CoA-ACK [<a href="https://tools.ietf.org/html/rfc5176" title="&quot;Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)&quot;">RFC5176</a>], Accounting-Response
            [<a href="https://tools.ietf.org/html/rfc2866" title="&quot;RADIUS Accounting&quot;">RFC2866</a>], etc.), the value of the MAC field is a hash of
            the entire packet except the Response Authenticator in the
            header of the RADIUS packet using a shared secret as the
            key, as follows.

            MAC = HASH-ALG(Key, Type + Identifier + Length + Attributes)
               where '+' represents concatenation

            If the request contained an instance of the MAC-Randomizer
            Attribute and the responder wishes to include an instance of
            the Message-Authentication-Code Attribute in the
            corresponding response, then the MAC-Randomizer Attribute
            from the request MUST be included in the response.

            If the Message-Authenticator-Code Attribute is included in a
            server response, the client SHOULD ignore the contents of
            the Response Authenticator.

            Implementation Notes

               When the hash is calculated, both the MAC field of the
               Message-Authenticator-Code Attribute and the String field
               of the Message-Authenticator Attribute (if any) MUST be
               considered to be zero-filled.

               The Message-Authentication-Code Attribute MUST be created
               and inserted in the packet before the Response
               Authenticator is calculated.

               Implementations SHOULD provide a means to provision a key
               (cryptographically separate from the normal RADIUS shared
               secret) to be used exclusively in the generation of the
               Message-Authentication-Code.



<span class="grey">Zorn, et al.                  Informational                    [Page 15]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-16" id="page-16" href="#page-16" class="invisible"> </a>
<span class="grey"><a href="https://tools.ietf.org/html/rfc6218">RFC 6218</a>           RADIUS Keying Material Transfer VSA        April 2011</span>


<span class="h2"><h2><a class="selflink" name="section-4" href="#section-4">4</a>.  Security Considerations</h2></span>

   It is RECOMMENDED in this memo that two new keys, a key encrypting
   key and a message authentication key, be shared by the RADIUS client
   and server.  If implemented, these two keys MUST be different from
   each other and SHOULD NOT be based on a password.  These two keys
   MUST be cryptographically independent of the RADIUS shared secret
   used in calculating the Response Authenticator [<a href="https://tools.ietf.org/html/rfc2865" title="&quot;Remote Authentication Dial In User Service (RADIUS)&quot;">RFC2865</a>], Request
   Authenticator [<a href="https://tools.ietf.org/html/rfc2866" title="&quot;RADIUS Accounting&quot;">RFC2866</a>] [<a href="https://tools.ietf.org/html/rfc5176" title="&quot;Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)&quot;">RFC5176</a>], and Message-Authenticator
   Attribute [<a href="https://tools.ietf.org/html/rfc3579" title="&quot;RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)&quot;">RFC3579</a>]; otherwise, if the shared secret is broken, all
   is lost.

   To avoid the possibility of collisions, the same MAC key SHOULD NOT
   be used with more than 2^(n/2) messages, where 'n' is the length of
   the MAC value in octets.

   If a packet that contains an instance of the Keying-Material
   Attribute also contains an instance of another, weaker key transport
   attribute (e.g., MS-MPPE-Recv-Key [<a href="https://tools.ietf.org/html/rfc2548" title="&quot;Microsoft Vendor-specific RADIUS Attributes&quot;">RFC2548</a>]) encapsulating identical
   keying material, then breaking the weaker attribute might facilitate
   a known-plaintext attack against the KEK.

<span class="h2"><h2><a class="selflink" name="section-5" href="#section-5">5</a>.  Contributors</h2></span>

   Hao Zhou, Nancy Cam-Winget, Alex Lam, Paul Funk, and John Fossaceca
   all contributed to this document.

<span class="h2"><h2><a class="selflink" name="section-6" href="#section-6">6</a>.  Acknowledgements</h2></span>

   Thanks (in no particular order) to Keith McCloghrie, Kaushik Narayan,
   Murtaza Chiba, Bill Burr, Russ Housley, David McGrew, Pat Calhoun,
   Joel Halpern, Jim Schaad, Greg Weber, and Bernard Aboba for useful
   feedback.

<span class="h2"><h2><a class="selflink" name="section-7" href="#section-7">7</a>.  References</h2></span>

<span class="h3"><h3><a class="selflink" name="section-7.1" href="#section-7.1">7.1</a>.  Normative References</h3></span>

   [<a name="ref-FIPS" id="ref-FIPS">FIPS</a>]     National Institute of Standards and Technology, "Secure
              Hash Standard (SHS)", FIPS PUB 180-3, October 2008.

   [<a name="ref-NIST" id="ref-NIST">NIST</a>]     Dworkin, M., "Recommendation for Block Cipher Modes of
              Operation: The CMAC Mode for Authentication", NIST SP800-
              38B, May 2005.

   [<a name="ref-RFC2104" id="ref-RFC2104">RFC2104</a>]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", <a href="https://tools.ietf.org/html/rfc2104">RFC 2104</a>,
              February 1997.



<span class="grey">Zorn, et al.                  Informational                    [Page 16]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-17" id="page-17" href="#page-17" class="invisible"> </a>
<span class="grey"><a href="https://tools.ietf.org/html/rfc6218">RFC 6218</a>           RADIUS Keying Material Transfer VSA        April 2011</span>


   [<a name="ref-RFC2119" id="ref-RFC2119">RFC2119</a>]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", <a href="https://tools.ietf.org/html/bcp14">BCP 14</a>, <a href="https://tools.ietf.org/html/rfc2119">RFC 2119</a>, March 1997.

   [<a name="ref-RFC2865" id="ref-RFC2865">RFC2865</a>]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              <a href="https://tools.ietf.org/html/rfc2865">RFC 2865</a>, June 2000.

   [<a name="ref-RFC2866" id="ref-RFC2866">RFC2866</a>]  Rigney, C., "RADIUS Accounting", <a href="https://tools.ietf.org/html/rfc2866">RFC 2866</a>, June 2000.

   [<a name="ref-RFC2868" id="ref-RFC2868">RFC2868</a>]  Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
              M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
              Support", <a href="https://tools.ietf.org/html/rfc2868">RFC 2868</a>, June 2000.

   [<a name="ref-RFC3394" id="ref-RFC3394">RFC3394</a>]  Schaad, J. and R. Housley, "Advanced Encryption Standard
              (AES) Key Wrap Algorithm", <a href="https://tools.ietf.org/html/rfc3394">RFC 3394</a>, September 2002.

   [<a name="ref-RFC3579" id="ref-RFC3579">RFC3579</a>]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
              Dial In User Service) Support For Extensible
              Authentication Protocol (EAP)", <a href="https://tools.ietf.org/html/rfc3579">RFC 3579</a>, September 2003.

   [<a name="ref-RFC4086" id="ref-RFC4086">RFC4086</a>]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", <a href="https://tools.ietf.org/html/bcp106">BCP 106</a>, <a href="https://tools.ietf.org/html/rfc4086">RFC 4086</a>,
              June 2005.

   [<a name="ref-RFC4231" id="ref-RFC4231">RFC4231</a>]  Nystrom, M., "Identifiers and Test Vectors for
              HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and
              HMAC-SHA-512", <a href="https://tools.ietf.org/html/rfc4231">RFC 4231</a>, December 2005.

   [<a name="ref-RFC5176" id="ref-RFC5176">RFC5176</a>]  Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
              Aboba, "Dynamic Authorization Extensions to Remote
              Authentication Dial In User Service (RADIUS)", <a href="https://tools.ietf.org/html/rfc5176">RFC 5176</a>,
              January 2008.

<span class="h3"><h3><a class="selflink" name="section-7.2" href="#section-7.2">7.2</a>.  Informative References</h3></span>

   [<a name="ref-RFC2548" id="ref-RFC2548">RFC2548</a>]  Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
              <a href="https://tools.ietf.org/html/rfc2548">RFC 2548</a>, March 1999.

   [<a name="ref-RFC3748" id="ref-RFC3748">RFC3748</a>]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, Ed., "Extensible Authentication Protocol
              (EAP)", <a href="https://tools.ietf.org/html/rfc3748">RFC 3748</a>, June 2004.










<span class="grey">Zorn, et al.                  Informational                    [Page 17]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-18" id="page-18" href="#page-18" class="invisible"> </a>
<span class="grey"><a href="https://tools.ietf.org/html/rfc6218">RFC 6218</a>           RADIUS Keying Material Transfer VSA        April 2011</span>


Authors' Addresses

   Glen Zorn
   Network Zen
   227/358 Thanon Sanphawut
   Bang Na, Bangkok  10260
   Thailand

   Phone: +66 (0) 87 040 4617
   EMail: gwz@net-zen.net


   Tiebing Zhang
   Advista Technologies
   5252 Orange Ave., Suite 106
   Cypress, CA  90630
   US

   Phone: +1 (949) 242 0391
   EMail: tzhang@advistatech.com


   Jesse Walker
   Intel Corporation
   JF2-55
   2111 N.E. 25th Ave.
   Hillsboro, OR  97214-5961
   US

   Phone: +1 (503) 712-1849
   EMail: jesse.walker@intel.com


   Joseph Salowey
   Cisco Systems
   2901 Third Avenue
   SEA1/6/
   Seattle, WA  98121
   US

   Phone: +1 (206) 256-3380
   EMail: jsalowey@cisco.com









Zorn, et al.                  Informational                    [Page 18]

</pre><br>
<span class="noprint"><small><small>Html markup produced by rfcmarkup 1.108, available from
<a href="http://tools.ietf.org/tools/rfcmarkup/">http://tools.ietf.org/tools/rfcmarkup/</a>
</small></small></span>

</body></html>